-
Notifications
You must be signed in to change notification settings - Fork 97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make source_semantic_models property accessible from a DataflowPlanNode #1218
Make source_semantic_models property accessible from a DataflowPlanNode #1218
Conversation
Thank you for your pull request! We could not find a changelog entry for this change. For details on how to document a change, see the contributing guide. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good!! 🚀
metricflow/dataflow/dataflow_plan.py
Outdated
inside of each node, we make those properties of the DataflowPlan, and this node-level converter makes | ||
such properties easily accessible. | ||
""" | ||
return DataflowPlan(sink_nodes=(self,)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So simple 🤯
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
metricflow/dataflow/dataflow_plan.py
Outdated
@@ -188,3 +208,24 @@ def __init__(self, sink_nodes: Sequence[DataflowPlanNode], plan_id: Optional[Dag | |||
@property | |||
def sink_node(self) -> DataflowPlanNode: # noqa: D102 | |||
return self._sink_nodes[0] | |||
|
|||
def __complete_subgraph(self, node: DataflowPlanNode) -> Sequence[DataflowPlanNode]: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be a staticmethod
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, I can do that.
c1faf9a
to
909aabb
Compare
dc94cfc
to
31ee2df
Compare
909aabb
to
9ef3244
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚢 🚢 🚢
31ee2df
to
3a02ea7
Compare
9ef3244
to
45cf01f
Compare
3a02ea7
to
9769994
Compare
This change ultimately adds the source_semantic_models property to the DataflowPlan and adds a hook for enabling access to it from any arbitrary DataflowPlanNode. We currently have two use-cases for this, one in the cloud codebase that needs the semantic model inputs for a dataflow plan, and the upcoming predicate pushdown evaluation which needs the semantic model inputs for a given DataflowPlanNode. An earlier version of this change added the property directly to the DataflowPlanNode, which would satisfy both use cases above. The issue with having this property assigned directly to a DataflowPlanNode is that the property might be considered both a node-level and graph-level attribute, so it's not clear where to put the accessor. The solution we came up with for this was to allow access to a DataflowPlan DAG object built from the node, which would effectively encapsulate the subgraph represented by the node and its ancestors. Then we can access these subgraph properties through the DataflowPlan while making it clear to the caller that what they are asking for is a subgraph-level, rather than a node-level attribute.
45cf01f
to
f0c6cb9
Compare
This change ultimately adds the source_semantic_models property to
the DataflowPlan and adds a hook for enabling access to it from any
arbitrary DataflowPlanNode.
We currently have two use-cases for this, one in the cloud codebase
that needs the semantic model inputs for a dataflow plan, and the
upcoming predicate pushdown evaluation which needs the semantic model
inputs for a given DataflowPlanNode.
An earlier version of this change added the property directly to the
DataflowPlanNode, which would satisfy both use cases above. The issue
with having this property assigned directly to a DataflowPlanNode
is that the property might be considered both a node-level and graph-level
attribute, so it's not clear where to put the accessor.
The solution we came up with for this was to allow access to a DataflowPlan
DAG object built from the node, which would effectively encapsulate the
subgraph represented by the node and its ancestors. Then we can access
these subgraph properties through the DataflowPlan while making it clear
to the caller that what they are asking for is a subgraph-level, rather
than a node-level attribute.